Teleconferencing applications are increasingly popular, as business, industry, and even social groups discover that the advantages of a face to face meeting can be achieved from the convenience of remote locations. Accordingly, developers of computer software and hardware have tried to adapt modern technologies to the needs of teleconferencing with various degrees of limited success. Like file transfer applications, teleconferencing applications use packet transfer protocols that group data into packets for transport from a sender to a receiver.
FIG. 1 shows a memory array within main memory 304 that may buffer I/O packets. The array is generally structured of addressable SRAMs, DRAMs, or other devices storing data in buffers of data cells, the cells being addressable by a memory bus master such as a processor or DMA device within the same computer system. Each cell has therein a plurality of bytes of memory. Buffers may comprise different numbers of cells and therefore may be of any length, and may be either contiguous cells of memory or linked cells of memory. The linked-cell variety of memory requires additional addressing to point from cell to cell, but perhaps allows greater use of isolated free memory locations.
However, teleconferencing has several special requirements due to the real-time nature of teleconferencing. For example, real-time teleconferencing communicates in packets of non-uniform size, arriving at unpredictable times and, when more than two parties are participating in a teleconference, from different sources, and having different priorities. The non-uniformity of packet size is a function of the variety of data required in a video conference. Teleconferencing may communicate compressed video images having a large packet of full frame video image, followed by a series of smaller size packets of difference video images, accompanied by packets of audio data. Also, because teleconferencing generally does not include acknowledgment signals and often operate on asynchronous networks, a receiver cannot control or predict when packets arrive. Therefore, even when the data received is bursty, the receiver must have capacity to store at least some of the data until the processor can provide the data to the teleconference application. Multi-party teleconferencing may also complicate matters, as different applications sending data to a given receiver may use different packet sizes and different compression techniques, producing different size packets and requiring added complexity to the transport layer protocol (and lower layer protocols as well), since different buffer sizes may be necessary to accommodate the varying packets. Furthermore, because most teleconferencing has audio/sound/voice components as well as video, and because loss of a sound packet may be more disruptive to a teleconference than the loss of a video frame, receivers attempting to handle a shortage of buffer space in memory when a packet arrives must recognize a priority indicator in the packet. Memory handling is further complicated by the requirement imposed by many teleconferencing applications that data corresponding to a particular teleconference be stored in adjacent memory locations.
Most transport layer protocols, therefore, are inadequate for the task of handling the sort of data that may be expected in teleconferencing. Some low-level (i.e., transport layer and lower) protocols such as TCP/IP and ASDP were designed for file-transfer applications that do not operate in real time. Also, many of these protocols require retransmission of packets in which errors are detected, bogging down the information rate at which a sender may put data onto the network or other communication medium. Such protocols are inappropriate in real time applications like teleconferencing, where the loss of a single data frame or packet is inconsequential but repeated requests for retransmission could be problematic.
Also, in a real-time application, in addition to discarding packets that have errors, the receiver must also discard packets that do not fit into the input buffer, making buffer size a particularly acute problem. Large buffers sufficient to accommodate arbitrary packets waste memory, while small buffers would involve the loss of a lot of the packets. The input buffer in a real-time system is not sized by a TCP or ASDP protocol and therefore has a maximum data length into which can fit the input buffer or buffers, creating a situation in which additional data received by the receiver is discarded. Even if a process could somehow determine and detect an "unacceptable" rejection rate and reallocate memory to create larger buffers, such a reallocation could not presently be accomplished while data is being received. In other words, when a transport layer process is storing data into buffers, those buffers are inaccessible to higher-level processes that might be attempting to reallocate memory. Therefore, any reallocation must be performed when no data is being received, precisely when it will not be apparent to the receiver how long the data packets are. Intelligent components at the receiver, such as a CPU or a distributed direct memory access unit, also have memory demands, making memory management at the receiver problematic.
FIG. 2 shows one example of networked systems, specifically showing two systems on such a network or communication medium. Processors 150C and 155C are each connected via a network adapter 160 and 165, respectively, to a network medium 170. The network medium 170 may be a digital bus, a video coaxial cable, a fiber optic cable, or other medium through which information may be transferred from one location to another. It will be understood upon reference to FIG. 2 that other arrangements are possible, that the network may include more than two computer systems, and that each of the processors 150C and 155C may be connected via other network adapters or other communication medium adapters to other network or communication media. Although reference is made to networks and network media, it will be apparent upon reference to the specification of the present invention that other communication media such as a telephone line or other link may be used. It will also be apparent that the two systems may be coupled through a modem connected to each communication system.
Each of the processors in the computer systems shown in FIG. 2 has a video monitor at 150D and 155D, a video input 150A and 155A, an audio input 150B and 155B, a keyboard input and a mouse, and possibly other peripheral input/output devices connected thereto. It will be understood that each computer system may also comprise multiple processors sharing a network adapter, forming a local network within the larger network shown in FIG. 2. Computer systems such as 150 and 155 may connect to a number of network media having differing types of media substrates, and further having different network protocols. Processor 150C and 155C each display images on the video monitor 150D and 155D, respectively, and receive inputs from other peripherals. Processors may also be running computer programs, including application programs and transport layer programs, that may call one another and serve one another, exchanging data, addresses, and control signals.
FIG. 3 shows the system components of a general computer system, having a number of component devices, coupled over a network to a second computer system. Computer systems, stand alone servers, work stations, and other machines may be connected to one another across networks. A network may be a local network connecting a few machines to one another or a much wider network connecting large numbers of different types of machines. Many networks, especially wide area networks, connect machines operating on different platforms with different operating systems and 5 different microprocessors, but provide consistent protocols to allow the machines to communicate. Various approaches to networking are known in the art, including distributed networks and centrally administrative networks.
As shown in FIG. 3, a processor 302 is connected via a system bus 301 to a main memory 304, a read only memory 306, and a mass storage device 307. The main memory may be a volatile memory array composed of dynamic random access memory. The read only memory 306 may be composed of a CD ROM, an initialization cache, erasable programmable read only memory, EEPROM, flash memory, or other read only memories. The mass storage device 307 may be configured as a disk drive writing to, and reading from, hard disks, floppy disks, or other storage devices. Processor 302 may also have a cache, either a write back or read through configuration, storing frequently used values in a static random access memory or other memory array, the cache in some configurations being coupled directly to main memory 304. Various other intelligent devices may be connected to the bus 301, including direct memory access devices.
Also shown in FIG. 3, various peripherals exchange information via bus 301 with the processor 302, main memory 304, read only memory 306, and mass storage device 307. These peripherals include a display 321, generally a video monitor or printer. A keyboard 322 is also coupled to the bus 301, permitting alphanumeric entry. A cursor control 323 coupled to the bus 301 may be configured as a mouse or track ball. A sound output device 324, also coupled to the bus 301, may be configured as a loud speaker or a number of loud speakers. A video input device 325 may be configured as a video camera, a scanner, a fax input, or similar device, and is coupled to the processor 302 via bus 301. A sound input device 326, also coupled to the bus, may be configured as a microphone or a sound synthesizer, or may be a telephone connector. 6. Finally, a communication device 327, also coupled to the bus 301, allows communication between any of the above devices and the network medium 170 via the network adapter 160. It will be recognized that communication device 327 could be a modem, an internet card, or any network interface device, including a token network interface device or other FDDI device. It will also be apparent upon reference to the specification herein described that the communication medium may be any communication link, such as a telephone line or other link, and that the system shown in FIG. 3 may be coupled through the communication device 327 that may be a modem to another system not shown in the figure. In some embodiments, the networking medium is a digital communication medium, allowing high speed digital communication between computer systems over the network.
Two possible approaches to solving this problem have presented their own difficulties. First, because video compression is often implemented by transmitting periodically a full video frame, and between full video frames by transmitting difference frames that are much smaller in size than the full video frames, receiver systems that allocate one large block of memory for input buffering are highly inefficient. If a single large memory buffer is used to store input signals, sufficiently large to store a full frame image, than a large part of the time the smaller frames will not fill the buffer and will therefore waste a lot of memory. Second, if a linked list of fixed size buffers is used, in which the input or receiver protocol finds and allocates memory as data packets are received, services running on the receiver system may be unable to find data. Such services often require, or have performance that is enhanced by, collocating data in adjacent memory locations. Using a linked list of fixed size memory buffers scattered throughout memory would be problematic to such systems. A third alternative in which a linked list is first generated and then copied into adjacent memory locations can be very time consuming for the receiver CPU and also may require large amounts of additional memory to accomplish the copying.
The Macintosh Real-time video, audio, and data teleconferencing stream does not provide TCP, ASDP, or other error correcting protocols. Such error-correcting protocols generally send the data in packets of near-uniform packet sizes appropriate to the transmission medium, and although many of these protocols can receive data in a small number of predetermined other packet sizes, cannot process data arriving in packets of arbitrary length. Also, TCP, ASDP, and other low level packeting protocols include error correction at the packet level involving repetition of packets upon detection of an error, using a wait-for-acknowledge "handshake" protocols that is especially problematic in busy networks. Therefore, a need has arisen for an approach to low level packet-handling suitable for real-time applications that does not require retransmission, accommodating a plurality of arbitrary real-time teleconferencing applications communicating in packets of non-uniform size, arriving at unpredictable times and from different sources, and having different priorities, and providing the needed adjacency of data in memory.
Also, given that many network systems like ethernet have maximum packet size requirements, the packet-handling protocol should include a repackaging scheme corresponding to a particular data network, that "adapts" to a network by learning from the structure of data packets what size packets may be expected in the immediate future. Both TCP and ADSP have flow control as a feature of the protocol and the acknowledgment message sent over the network by the receiver to the sender. The flow control limits the amount of data a sender can put on to the network, and is implemented as a "window" of data, and if a sender places on the network more data than can fit into the window, the receiver will not send a confirmatory acknowledgment but rather will require retransmission. Once the window established by the TCP or ASDP protocol at the receiver, the protocol can allocate a buffer of sufficient size to store the window of data upon reception. However, if the CPU load varies significantly, and therefore the CPU cannot process data in the buffer at the receiver sufficiently fast, the buffer or buffers at the receiver may fill and the protocol may not be able to receive more data, then therefore the communication network will slow down as flow control messages are communicated from the receiver back to the sender.
Therefore, it would be desirable to provide a protocol at the receiver of a network communication package that heuristically determines, based on measurements taken directly from the node an appropriate buffer size sufficient to store incoming data packets without wasting memory at the receiver.